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(57) Abstract: The invention proposes a method for transmitting 
subscriber information from a first network element to a second net- 
work element, comprising the steps of inserting subscriber informa- 
tion in a specific message (1) of the same call control protocol that 
is used to establish the call; and sending the message from the first 
network element to the second network element. By this method, 
subscriber information can be easily uploaded from the first net- 
work element (e.g., a HSS) to the second network element (e.g., a 
CSCF). The invention also proposes a corresponding network sys- 
tem. 
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"EXTENDING SIP FOR UPLOADING SUBSCRIBER'S SERVICE PROFILE 

FROM HSS TO CSCF" 

5 

Field of the invention 

The present invention relates to a method a network 
10 system for transmitting subscriber information from a 
first network element to a second network element. 

BACKGROUND OF THE INVENTION 

15 

The present invention concerns the so-called subscriber 
profile. The subscriber profile holds subscription 
information about services and other parameters that have 
been assigned to a subscriber for an agreed contractual 

20 period. It includes information regarding subscribed 
services, subscribed QoS (Quality of Service) profile 
(i.e., service precedence (priority) , reliability, delay, 
throughput) etc. The data included in the subscriber 
profile are needed by the network element executing the 

25 service in order to handle the calls. 

The subscriber profile includes for a given user, e.g., 
user identities, subscribed services and profiles, 
service specific information, mobility management 
3 0 information, authorization information etc. 

In the 3GPP (Third Generation Partnership Project) 
Release 2000 (in the following referred to as R00) , this 
data are hold in the HSS (Home Subscriber Server) . Thus, 
35 the HSS is the master database for a given user. It is 
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responsible for keeping a master list of features and 
services (either directly or via servers) associated with 
a user, and for tracking of location of and means of 
access for its users, i.e., provides the subscriber 
profile. 

During normal calls, this subscriber profile is required 
by other network elements which handle the calls. Hence, 
the subscriber profile has to be conveyed to these other 
network elements. 

Such a network element is a so-called Call State Control 
Function, for example. The CSCF is the call control 
entity in the all-IP architecture responsible for 
supervising the call (or IP multimedia call) . It handles 
the call establishment, supervision and disconnection 
signalling and may control resources associated with the 
call such as media gateways processing the various call 
related media streams . 

A CSCF can fulfill different roles in an IP multimedia 
call signaling path, for example as a Serving CSCF (S- 
CSCF) , an Interrogating CSCF (I -CSCF) or an Originating 
CSCF (O-CSCF) , depending on which function it fulfills 
during a call. 

The Serving CSCF supports the signalling interactions 
with the UE (User Equipment) , in particular, it provides 
a Serving Profile Database (SPD) described below. The 
Home Subscriber Server (HSS) is updated with the Serving 
CSCF address and the HSS sends the subscriber data to the 
Serving CSCF for storage. 



The Interrogating CSCF (I-CSCF) is used for mobile 
35 terminated communications and is used to determine how to 
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route mobile terminated calls. The Interrogating CSCF 
interrogates the HSS for information to enable the call 
to be directed to the Serving CSCF. 

Moreover, an Originating CSCF (O-CSCF) is the CSCF where 
the originating party is registered and where the 
originating party services are handled. On the- other 
hand, the S-CSCF is the CSCF where the terminating party 
is registered and where the terminating party services 
are handled. 

For mobile terminated communications both Serving CSCF 
and Interrogating CSCF functionality can be involved. For 
mobile originated communications Interrogating CSCF 
functionality is not required. 

For controlling a call between the different CSCFs and 
the UE connected thereto, a call control protocol is 
required. One of such call control protocols is the so- 
called Session Initiation Protocol. In the following, 
some aspects of SIP are described in short. 

SIP is a general -purpose tool for the initiation, 
modification, and termination of sessions. That is, SIP 
is an application-layer control (signalling) protocol 
that can establish, modify and terminate multimedia 
sessions or calls with one or more participants. These 
sessions include Internet multimedia conferences, 
Internet telephone calls, multimedia distribution and 
similar applications. Members in a session can 
communicate via multicast or via a mesh of unicast 
relations, or a combination of these. As a core part of 
its functionality, SIP carries the ports, IP addresses 
and domain names needed to describe the sessions it 
controls . 
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SIP can be used to initiate sessions' as well as to invite 
members to sessions that have been advertised and 
established by other means. 

In the following, items concerning SIP are described 
which are necessary for understanding the present 
invention. 

In SIP, a plurality of different requests are exchanged. 
A request is composed by a request line followed by a 
header and, optionally, a message body. 

In the following, an example a for request is listed: 

INVITE sip: UE (B) @HSS . ipt . operator . com SIP/2.0 
Via : I-CSCF . ipt . operator . com 
From: UE (A) 

To : UE (B) @ipt . operator . com 
Content-type : application/sdp 
Content -length: . . . 

<SDP information in the message body> 

The request line is made up as follows: 

Request-Line = Method Request-URI SIP-Version 

A method is a predefined procedure. Currently, in SIP the 
methods INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER 
are defined. For simplifying the description, only the 
methods INVITE and ACK are described in the following as 
examples in short. 
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The INVITE method indicates that a user is being invited 
to participate in a sessions. Thus, the message body of a 
corresponding INVITE request contains a description of 
the session to which the callee is being invited. 

The ACK method is used in the ACK request to confirm that 
a client has received a final response to an INVITE 
request. ACK is used only with INVITE requests. The ACK 
request may contain a message body with the final session 
description to be used by the callee. If the ACK message 
body is empty, the callee uses the session description in 
the INVITE request. 

The request -URI is a SIP URL (Uniform Resource Locator) 
or a general URI (Uniform Resource Identifier) . It 
indicates the user or service to which this request is 
being addressed. 

Furthermore, the request-line comprises the SIP version 
(e.g., SIP/2.0) in order to indicate the recipient which 
SIP version is used. 

The header of the SIP request comprises a plurality of 
fields. In the following, only those fields are described 
in short which are important for the present embodiment. 

A field "Via" indicates the path taken by the request so 
far. This prevents request looping and ensures replies 
take the same path as the requests, which assists in 
firewall traversal and other unsusual routing situations. 
That is, each time a request is proxied, a new Via- field 
is added. 
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A field "From" indicates the initiator of the request, 
whereas the field "To" indicates the recipient of the 
request . 

5 A field "Content -Length" indicates the size of the 

message body, in decimal number of octets, sent to the 
recipient . 

A field "Content -Type 11 indicates the media type of the 
10 message body sent to the recipient. 

A field "Call -ID" uniquely identifies a particular 
invitation or all registrations of a particular client. 

15 A field "CSeq" indicates a command sequence. It contains 
the request method (e.g., INVITE) and a single decimal 
sequence number chosen by the requesting client. 

The message body comprises, for example, a description of 
20 the multimedia connection to which a recipient is 

invited. For example, the so-called Session Description 
Protocol (SDP) is used for this purpose. 

On receiving a request, the recipient can send a 
25 response. For example, in case of an INVITE request, the 
recipient can agree to participating in the call by 
sending a so-called 200 OK response. A response is 
basically similar to a request, although the request-line 
is replaced by a status-line which in particular 
30 comprises a status code, which is in the above example 
200. This value indicates OK. The header of a response 
can contain similar fields as the request. For example, 
in case of an 200 OK response to an INVITE request, the 
CSeq field contains the same value, e.g., INVITE 1. 



35 
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In Fig, 1, a basic example for network including the 
above -described network elements is shown. In detail, two 
User Equipments (UE) UE1 and UE2, and a plurality of 
CSCFs are shown. O-CSCF and I-CSCF comprise a Subscriber 
5 Profile Database (SPD) and each CSCF comprises a SIP 
message processor for handling the' SIP requests and 
responses. As mentioned above, whether a certain CSCF is 
an O-CSCF, an I-CSCF or an S-CSCF depends on the function 
the CSCF- has to fulfill. 



In this example, UE1 originates a call to UE2 . Thus, the 
CSCF to which it is connected, is an O-CSCF. The O-CSCF 



tries to obtain the address of UE2 1 s S-CSCF by referring 
15 to an HSS. The I-CSCF obtains the address of the 
corresponding S-CSCF of UE2 and forwards the call 
thereto. 

It is noted that in Fig. 1 the SPD in the O-CSCF and the 
20 S-CSCF has to interact with the HSS in the home domain to 
receive profile information for the R00 all-IP network 
user and store them. Furthermore, it notifies the home 
domain of initial user's access. In addition, it may 
cache access related information (e.g. terminal IP 
25 address (es) where the user may be reached etc.). 

In this example, only the I-CSCF has to access the HSS 
for obtaining information regarding the location etc. of 
UE2. Thus, the CSCF has to obtain a subscriber profile 
30 from a HSS in order to handle the call according to UE2 1 s 
services . 



10 



forwards a call request to an I-CSCF which, in turn, 



In R00, there is defined an interface Cx between the HSS 
and the CSCF. However, it is not defined yet how a 
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an CSCF via this interface. 



5 SUMMARY OF THE INVENTION 

Therefore, the object underlying the invention resides in 
removing the above drawbacks of the prior art . 

10 This object is solved by a method for transmitting 

subscriber information from a first network element to a 
second network element, comprising the steps of 

inserting subscriber information in a specific 
message of the same call control protocol that is used to 
15 establish the call; and 

sending the specific message from the first network 
element to the second network element. 

In addition, the invention proposes a network system 
20 comprising a first network element and a second network 

element, wherein 

\ first network element is adapted to insert 

subscriber information in a specific message of the same 

call control protocol that is used to establish the call, 
25 and to send the specific message to the second network 

element . 

Thus, according to the invention the subscriber 
information are inserted in a specific message of the 
30 same call control protocol that is used to establish the 
call . 

Therefore, according to the invention, an easy way of 
subscriber information uploading from one network element 
35 to another is provided. 
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An advantage of the invention is that there is no need 
for an additional protocol for profile uploading 
purposes. That is, the same call control protocol used 
5 for other call control purposes in the network can be 
used. Thus, the system can be kept less complex. 

In case the subscriber information have been received 
successfully by the second network element, a 
10 confirmation message may be sent from the second network 
element to the first network element. Thus, a successful 
uploading can easily be indicated to the first network 
element . 

15 The call control message can be a PROFILE request based 
on the Session Initiation Protocol (SIP) , the subscriber 
information being inserted in the message body of the 
request. That is, according to the invention, a new SIP 
method for profile uploading purposes is introduced. 

2 0 Since SIP is already chosen as the call control protocol 
in R00, for example, no complex additional protocol is 
required, only an extended SIP (i.e., SIP including the 
new PROFILE request) is necessary. 

25 The confirmation message is a SIP 200 OK message. In 

addition, the other SIP responses can be used to indicate 
failure situations . 

The subscriber information can be a subscriber profile. 

30 

The first network element can be a Home Subscriber Server 
(HSS) and the second network element can be a Call State 
Control Function (CSCF) . Thus, the invention provides a 
protocol for conveying subscriber information via the Cx 
35 interface. 
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The Call State Control Function (CSCF) may be a Serving 
Call State Control Function (S-CSCF) or an Interrogating 
Call State Control Function (I -CSCF) . 

Alternatively, the first network element can be a Serving 
Call State Control Function (S-CSCF) and the second 
network element can be an Interrogating Call State 
Control Function (I -CSCF) . Thus, also uploading between 
two CSCFs is possible. This is advantageous during a 
dynamic CSCF selection, for example. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be more readily understood 
with reference to the accompanying drawings in which: 

Fig. 1 shows a network including UEs, CSCFs and HSS, 

Fig. 2 shows a procedure for profile uploading according 
to an embodiment of the invention, 

Fig. 3 shows a procedure for registration on network 
level according to the embodiment, and 

Fig. 4 shows a procedure for call delivery according to 
the embodiment. 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 



35 



In the following, a preferred embodiment of the invention 
is described in more detail with reference to the 
accompanying drawings . 
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In particular, according to the embodiment described 
below, uploading of a subscriber profile from a first 
network element, e.g., a Home Subscriber Server (HSS) , to 
5 a second network element, e.g., a Call State Control 
Function (CSCF) is performed by using a specific call 
control protocol. This call control protocol is 
preferably also used in the network for other purposes. 

10 In this embodiment, the Session Initiation Protocol (SIP) 
is used as the call control protocol. 

According to the present embodiment, SIP is extended for 
uploading subscribers 1 service profile from HSS to CSCF. 

15 

That is, according to the embodiment a new SIP method for 
profile downloading is introduced, which is referred to 
as the SIP PROFILE method in the following 

20 It should always be the HSS who initiates the PROFILE 
request, this request should contain the subscriber 
profile data. The CSCF should respond to the request in 
successful case with a 200 OK. 

25 There are several alternatives for subscriber profile 

data representation conveyed in the PROFILE request, e.g. 
XML (eXtendend Markup Language) , HTML (Hyper Text Markup 
Language) . In the present embodiment, HTML is used for 
profile data representation. 

30 

Fig. 2 shows the profile uploading using the newly 
introduced PROFILE method. In step 1, the PROFILE request 
is sent to the CSCF, and the CSCF answers with a 200 OK 
response in case the subscriber profile was successfully 
35 received. 
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In the following, a PROFILE request including the new 
PROFILE method is listed: 

PROFILE sip :CSCF. ipt.operator.com SIP/2.0 

Via : HSS . ipt . operator . com 

From : UE@HSS . ipt . operator . com 

To : UE@ipt . operator . com 

Call - ID : 123456@HSS . ipt . operator . com 

Cseq: 1 PROFILE 

Content -type : text /html 

Content -length: . . . 

<Subscriber profile represented with HTML> 

That is, by the new PROFILE method, the subscriber 
profile is inserted in the message body. Hence, only this 
one message 1 (i.e., the PROFILE request) is necessary to 
transmit the subscriber profile to the CSCF. 

In case the message 1 was received successfully, the CSCF 
answers with a 200 OK response as follows: 

2. SIP/2.0 200 OK 

Via : HSS . ipt , operator . com 

From : UE@HSS . ipt . operator . com 

To : UE@ipt . operator . com 

Call-ID : 123456@HSS . ipt . operator . com 

Cseq: 1 PROFILE 

Content - length : 0 
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Thus, if the HSS receives a 200 OK response, it knows 
immediately that the subscriber profile was successfully 
transmitted. 

5 The profile uploading as mentioned above is basically 
needed in two major scenarios: registration and mobile 
terminated call delivery. 

Next, these two scenarios are described with reference to 
10 Figs . 3 and 4 . 

Fig. 3 illustrates a registration procedure of a User 
Equipment UE. 

15 In message Al, a SIP REGISTER request is sent from the UE 
to the S-CSCF. The REGISTER request is used in order to 
register an address listed in the To header field with a 
SIP server. 

2 0 That is, the meaning of the header fields is defined 

slightly different from those of, e.g., the INVITE 
request. In detail, the To header field contains the 
address whose registration is to be created (or updated) . 
The From header field contains the address of the person 
25 (or entity) responsible for the registration. Since these 
addresses are not used in the way as they are in other 
request types (e.g., the INVITE request), they are 
referred to as "address-of -record" . The Request-URI 
(included in the request -line) names the destination of 

3 0 the registration request, i.e., the domain of the 

registrar. 



In the procedure illustrated in Fig. 3, message Al is a 
SIP REGISTER request. This message is received by the S- 
35 CSCF. 
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Al . 



REGISTER sip:S-CSCF. ipt.operator.com SIP/2.0 
Via: ab.cd.de: : 11. 11 //UE's IP-address 
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From : UE@ipt . operator . com 
To : UE@ipt . operator . com 

In order to perform the requested registration of the UE, 
the S-CSCF has to know the subscriber profile. Hence the 
REGISTER request has to be forwarded to the HSS. The S- 
CSCF finds the domain name of HSS based on the value of 
the To header. S-CSCF proxies the REGISTER message 
further towards the HSS in message A2 . 

A2. REGISTER sip : HSS . ipt . operator . com SIP/2.0 
Via : S - CSCF . ipt . operator . com 
Via: ab.cd.de: :11.11 
From : UE@ipt . operator . com 
To : UE@ipt . operator . com 

Thereafter, the HSS performs profile downloading with the 
S-CSCF. This is effected as described above. 

That is, the subscriber profile is immediately inserted 
in a PROFILE request which is sent to the S-CSCF in A3. 
This is performed as described above with respect to Fig. 
2. That is, the PROFILE request is sent from the HSS to 
the S-CSCF which responds with a 200 OK response. 

On receiving the 200 OK message from the S-CSCF, the HSS 
knows that the subscriber profile downloading was 
successful and sends itself a 200 OK message A4 to the S- 
CSCF. 



35 
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A4. 



SIP/2. .0 200 OK 

Via: S-CSCF. ipt.operator.com 

Via: ab.cd.de: : 11. 11 

From : UE@ipt . operator . com 

To: UE@ipt.operator.com 

Cseq: 1 REGISTER 



This message is forwarded to the UE in message A5. 

10 

A5. SIP/2.0 200 OK 



After this message, the registration procedure has been 
successfully completed. 



Next, as a further example where the profile downloading 
according to the present embodiment can be used, a call 
delivery is described below with respect to Fig. 4. 

25 It is noted that here, REP (Remote Endpoint) represents 
the originating side of the call, e.g., a UE (A) and an 0- 
CSCF together. 



Via: ab.cd.de: : 11. 11 



15 



From : UE@ipt . operator . com 
To : UE@ipt . operator . com 
CSeq: 1 REGISTER 



20 



In a first message Bl, an INVITE request is sent from the 
30 REP to the interrogating CSCF, i.e., the I-CSCF. 
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Bl. INVITE sip:UE(B)@I -CSCF.ipt.operator.com SIP/2.0 
Via: REP 
From: UE(A) 

To : UE (B) @ipt . operator . com 
Content -type : application/sdp 
Content -length: . . . 

<SDP information in the message body> 

In message B2, the I-CSCF proxies the INVITE message to 
the ESS. 

B2. INVITE sip:UE(B)@HSS. ipt.operator.com SIP/2.0 
Via : I-CSCF . ipt , operator . com 
Via: REP 
From: UE(A) 

To: UE (B)@ipt .operator .com 
Content - type : appl icat ion/ sdp 
Content- length: . . . 

<SDP information in the message body> 



25 



In this case, the HSS gives the answer that UE(B) has 
temporarily moved by responding with a 302 Moved 
Temporarily Response in message B3 . 
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B3. 



SIP/ 2.0 3 02 Moved temporarily 
Via : I-CSCF . ipt . operator . com 
Via: REP 



5 



From: UE (A) 

To : UE (B) @ipt . operator . com 

Contact: UE (B) OS-CSCF . ipt . operator . com 



This request comprises a header field "Contact" which 
10 indicates a URL or URI where the user can be reached for 
further communications. 

Thereafter, the I-CSCF sends an acknowledgment ACK 
request to the HSS in message B4 . 



At this point the HSS may initiate a profile uploading 
with the I-CSCF, if service control mechanism also 
resides in the I-CSCF. This is performed as described 
25 above with respect to Fig. 2. That is, the PROFILE 

request is sent from the HSS to the I-CSCF which responds 
with a 200 OK response. 



15 



B4. ACK sip :UE(B) ©HSS.ipt.operator.com SIP/2.0 
Via: I-CSCF. ipt . operator . com 
From: UE(A) 

To : UE (B) @ipt . operator . com 



Then, the I-CSCF proxies the INIVITE message to the S- 
3 0 CSCF in message B6 . 
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B6. 



INVITE sip:UE(B)@S -CSCF.ipt.operator.com SIP/2 . 0 
Via: I-CSCF. ipt.operator.com 
Via: REP 



From: UE(A) 



To : UE (B) @ipt . operator . com 
Content -type : application/sdp 
Content -length: . . . 



<SDP information in the message body> 



10 



Thereafter, a regular call setup is continued. Thus, a 
detailed description of the following messages is 
omitted. 

15 

In message B7, the INVITE request is transmitted to the 
UE(B) , which acknowledges the INVITE request with a 200 
OK response in message B8 . This 200 OK message is 
forwarded to the REP (i.e., the UE(A)) in messages B9 and 
20 BIO. Finally, UE (A) acknowledges the OK of UE(B) by 

sending an ACK request to UE(B) in messages Bll to B13 . 
Thereafter, the multimedia session can begin. 

With respect to the profile downloading in this case 
25 (i.e., message B5) , it is noted that in this case in 
particular the location information included in the 
subscriber profile is important. For example, maybe user 
UE(B) is not entitled to use his mobile station in the 
location where he currently is. Since the subscriber 
30 profile can basically divided in location (routing) 
information and service profile, it would also be 
sufficient in this case when only the location 
information (and/or service information which is location 
depending) is mandatorily downloaded to the I-CSCF. 
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As mentioned above, the representation of the subscriber 
profile in HTML is only an example, and, as a matter of 
course, other appropriate representations can be used. 

The service profile part of the subscriber profile itself 
depends on the service execution architecture to be 
adopted in 3GPP for R00. Basically, there are three 
possibilities: CAMEL (Customized Applications for Mobile 
network Enhanced Logic) , SIP and OSA (Open Service 
Architecture) . 

The OSA (Open Service Architecture) defines an open API 
(Application Programming Interface) for the design, 
implementation, control and execution of services and 
applications provided by third party service providers. 

In case CAMEL is used for the service profile, then CSI 
(CAMEL Subscriber Information) using ASN.l representation 
is utilized for representing the service profile. 

In SIP, the service profile can be a script written in a 
script language, which may be, e.g., a common script 
language like Call Processing Language (CPL) , Common 
Gateway Interface (CGI) or Java Enhanced SIP (JES) . 

In case of OSA, any of the above described service 
profiles can be used in an appropriate way. 

The above description and accompanying drawings only 
illustrate the present invention by way of example. Thus, 
the embodiment may vary within the scope of the attached 
claims . 
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Claims 

1. A method for transmitting subscriber information 

5 from a first network element to a second network element, 
comprising the steps of 

inserting subscriber information in a specific • 
message (1) of the same call control protocol that is 
used to establish the call; and 
10 sending the message' (1) from the first network 

element to the second network element . 

2. The method according to claim 1, further comprising 
the step of 

15 sending a confirmation message (2) from the second 

network element to the first network element in case the 
subscriber information have been received successfully by 
the second network element. 

20 3. The method according to claim 1, wherein the call 

control message is a PROFILE request based on the Session 
Initiation Protocol (SIP) , the subscriber information 
being inserted in the message body of the request. 

25 4. The method according to claim 2, wherein the call 

control message is a PROFILE request based on the Session 
Initiation Protocol (SIP) , the subscriber information 
being inserted in the message body of the request, and 
the confirmation message (2) is a SIP 200 OK message. 

30 

5. The method according to claim 1, wherein the 
subscriber information is a subscriber profile. 

6. The method according to claim 1, wherein the first 
35 network element is a Home Subscriber Server (HSS) and the 



• 
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second network element is $ Call State Control Function 
(CSCF) . 

7. The method according to claim 6, wherein the Call 
5 State Control Function (CSCF) is a Serving Call State 

Control Function (S-CSCF) . 

8. The method according to claim 6, wherein the Call 
State Control Function (CSCF) is an Interrogating Call 

10 State Control Function (I-CSCF) . 

9. The method according to claim 1, wherein the first 

' • i 

network element is a Serving Call State Control Function 
(S-CSCF) and the second network element is an 
15 Interrogating Call State Control Function (I-CSCF) . 

10. A network system comprising a first network element 
and a second network element, wherein 



20 subscriber information in a specific message (1) of the 
same call control protocol that is used to establish the 
call, and to send the message (1) to the second network 
element . 

25 11. The network system according to claim 10, wherein 
the second element is adapted to send a confirmation 
message (2) to the first network element in case the 
subscriber information have been received successfully by 
the second network element . 

30 

12. The network system according to claim 10, wherein 
the call control message is a PROFILE request based on 
the Session Initiation Protocol (SIP) , the subscriber 
information being inserted in the message body of the 
35 request. 



the first network element is adapted to insert 
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13. The network system according to claim 11, wherein 
the call control message is a PROFILE request based on 
the Session Initiation Protocol (SIP) , the subscriber 

5 information being inserted in the message body of the 

request, and the confirmation message (2) is a SIP 200 OK 
message. 

14. The network system according to claim 10, wherein 
10 the subscriber information is a subscriber profile. 

15. The network system according to claim 10, wherein 
the first network element is a Home Subscriber Server 
(HSS) and the second network element is a Call State 

15 Control Function (CSCF) . 

16. The network system according to claim 15, wherein 
the Call State Control Function (CSCF) is a Serving Call 
State Control Function (S-CSCF) . 

20 

17. The network system according to claim 15, wherein 
the Call State Control Function (CSCF) is an 
Interrogating Call State Control Function (I-CSCF) . 

25 18. The network system according to claim 10, wherein 

the first network element is a Serving Call State Control 
Function (S-CSCF) and the second network element is an 
Interrogating Call State Control Function (I-CSCF) . 



WO 02/19749 



PCT/EPOO/08590 



1/3 




U_ 

O 

CO 

o 

I 

CO 



a 

CO 



LL 




\ 


O 




Q 


CO 




ft. 


o 

1 




CO j 







LU 

< 
CO 
CO 
LU 



0_ 

CO 



O 
CO 
CO 
Hi 

o 
o 

01 
Q- 



LU 

CD 
< 
CO 
CO 
LU 

Q- 

CO 



O 
CO 
CO 
LU 
O 

o 
on 
ft. 



(3 

LL 



O 





LU 
D 



WO 02/19749 



2/3 



PCT/EP00/08590 



HSS 




CSCF 




1. PROFILE 










2. 200 OK 






« — 










FIG 


.2 



UE S-CSCF.ipt.operator.com HSS.ipt.operator.com 




A1. REGISTER „ 


A2. REGISTER 








A3. PROFILE DOWNLOADING 


t A5. 200 OK 


4 A4. 200 OK 









FIG. 3 



WO 02/19749 PCT7EPO0/0859O 

3/3 



Q_ 

lil 
CH 



E 
o 
o 



2 

Q. 
O 



U_ 

O 

CO 

o 

I 



E 

8 

O 

-4— » 

CD 
CL 
O 



CO 
CO 



E 
o 
q 

o 

2 

<D 
CL 
O 



O 
(0 

o 

f 

co 




Lil 
H 

> 
Z 



CO 



111 

> 



CM 
CO 



3 






o 


< 


< 


UK 


CO 


CL 






ILi 




H 




Q 




LLI 




> 




o 




n 




CO 









Q 



O 
Q 

Lil 
_J 

LL 
O 
DC 
Q. 

to 

CD 



LU 

> 



CO 
CO 



O 

o 
o 

CM 

CD 
CD 



i 






O 




< 






o 


CO 


o 




o 




CM 




O 




x— 




CQ 





CM 
CO 



g 

LL 



ill 

> 



0Q 



o 

o 
o 

Oi 

00 
CD 



CO 
CO 



INTEBHATIONAL SEARCH REPORT 



?rnat|ona^^fttatlon No 

rCT/EPW08590 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04Q7/24 H04L29/06 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 H04Q H04L 



Documentation searched other than minimum documentation to the extent that such documents are included In the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 

EPO-Internal 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category e 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



GIUSEPPE RICAGNI: "UMTS all-IP Mobility 
Management, Call and session control 
Procedures" 

INTERNET DRAFT - ANTONELLA NAPOLITANO 
CSELT, ITALTEL, 

24 March 2000 (2000-03-24), pages 1-24, 
XP002149519 

Page 5-8, Paragraph "Reference Model" 
Page 8-9, Paragraph "Attach Function" 
figures 1,3 

W0 99 60801 A (ERICSSON TELEF0N AB L M) 
25 November 1999 (1999-11-25) 
page 4, line 16 -page 5, line 6 

-/- 



1,10 



1,10 



| X| Further documents are listed in the continuation of box C. 



0 



Patent family members are listed in annex. 



° Special categories of cited documents : 

'A' document defining the general slate of the art which Is not 
considered to be of particular relevance 

'E' earlier document but published on or after the international 
filing date 

•L' document which may throw doubts on priority claim(s) or 
which Is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O' document referring to an oral disclosure, use, exhibition or 
other means 

'P' document published prior to the International filing date but 
later than the priority date claimed 



T later document published after the International filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
Invention 

■X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an Inventive step when the document Is taken alone 

*Y' document of particular relevance; the claimed invention 
cannot be considered to involve an inventive step when the 
document i3 combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

'&' document member of the same patent family 



Date of the actual completion of the international search 



25 June 2001 



Date of mailing of the international search report 



02/07/2001 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL~2280HVRqswqk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax (+31-70) 340-3016 



Authorized officer 



Pacholec, D 



Form PCT/1SA/210 (second sheet) (July 1882) 



page 1 of 2 



INTEBtfATIONAL SEARCH REPORT 



( ematlon^^^kation No 
rCT/EP^P)8590 



C.(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation of document, with indication.where appropriate, of the relevant passages 



Relevant to claim No. 



WO 00 79756 A (ERICSSON TELEFON AB L M) 

28 December 2000 (2000-12-28) 

page 13, line 5 -page 14, line 9; figures 

3B,3C 



1-20 



Form PCT/ISA/210 (continuation of second sheet) (July 1992) 



page 2 of 2 



INTEJ 



JIONAL SEARCH REPORT 

on on patent family members 



ernatlona^^Bpation No 

L rCT/EP^f08590 



Patent document 
cited in search report 



Publication 



Patent family 
member(s) 



Publication 
date 



WO 9960801 



25-11-1999 



AU 
BR 
EP 



4662999 A 
9910633 A 
1078537 A 



WO 0079756 



28-12-2000 



AU 
AU 
WO 



5862400 A 
5862500 A 
0079741 A 



06-12-1999 
30-01-2001 
28-02-2001 



09-01-2001 
09-01-2001 
28-12-2000 



Form PCT/ISA/210 (patent family amwx) (July 1982) 



